Hardware secret usage limits

ABSTRACT

A hardware secret is securely maintained in a computing device. The device operates in accordance with a usage limit corresponding to a limited number of operations using the hardware secret that the device is able to perform. Once the device reaches a usage limit, the device becomes temporarily or permanently unable to perform additional operations using the hardware secret.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.14/149,710, filed Jan. 7, 2014, entitled “HARDWARE SECRET USAGE LIMITS,”which incorporates by reference for all purposes the full disclosure ofco-pending U.S. patent application Ser. No. 14/149,698, filed Jan. 7,2014, entitled “PASSCODE VERIFICATION USING HARDWARE SECRETS” and U.S.patent application Ser. No. 14/149,721, filed Jan. 7, 2014, entitled“DISTRIBUTED PASSCODE VERIFICATION SYSTEM.”

BACKGROUND

The security of resources is of importance in many contexts.Unauthorized access to various types of data, for example, can havenumerous adverse consequences, such as unrealized revenue, data loss, aloss of customer goodwill, damage to reputation, and/or even civil orcriminal penalties. Likewise, unauthorized access to property, whetherphysical property or intellectual property, can result in similaradverse consequences, including the loss of the property itself. As aresult, many systems have developed over the years for controllingaccess to resources. An automated teller machine, for example, oftenrequires simultaneous possession of a bank card and a personalidentification number (PIN). Various websites and other servicesprovided over the Internet and other networks often require users toenter passwords before certain types of access are granted. Even accessto real property often requires proof of possession of some type ofcredential (e.g., PIN, password, physical key and/or possession of anaccess card) before access is granted.

In many contexts, it is difficult to find a balance between security andusability. In the case of passwords, for example, users often selectpasswords to be easy to remember. Typically, this means that passwordscontain some type of semantic meaning to their holders. Similarly, PINsoften are of a small number of digits (e.g., 4) and also often picked tohave some sort of semantic meaning. Therefore, the size of a passwordspace and/or the number of passwords that users actually use isrelatively small, making certain types of security attacks (e.g.,automated password guessing) more likely to succeed.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments in accordance with the present disclosure will bedescribed with reference to the drawings, in which:

FIG. 1 shows an illustrative example of an environment in which variousembodiments can be implemented;

FIG. 2 shows an illustrative example of an environment in which variousembodiments can be implemented;

FIG. 3 shows an illustrative example of a process for controlling accessto a resource in accordance with at least one embodiment;

FIG. 4 shows an illustrative example of a process for generating a hashfrom a passcode in accordance with at least one embodiment;

FIG. 5 shows an illustrative example of an environment in which variousembodiments can be implemented;

FIG. 6 shows an illustrative example of a process for populating a setof one-time passcodes in accordance with at least one embodiment;

FIG. 7 shows an illustrative example of a device that may be used inaccordance with various embodiments;

FIG. 8 shows an illustrative example of a process for enforcing a usagelimit in accordance with at least one embodiment;

FIG. 9 shows an illustrative example of another process for enforcing ausage limit in accordance with at least one embodiment;

FIG. 10 shows an illustrative example of yet another process forenforcing a usage limit in accordance with at least one embodiment;

FIG. 11 shows an illustrative example of yet another process forenforcing a usage limit in accordance with at least one embodiment;

FIG. 12 shows an illustrative example of a process for increasing ausage limit in accordance with at least one embodiment;

FIG. 13 shows an illustrative example of a distributed passcodeverification system in accordance with at least one embodiment;

FIG. 14 shows an illustrative example of a distributed passcodeverification system in accordance with at least one embodiment; and

FIG. 15 illustrates an environment in which various embodiments can beimplemented.

DETAILED DESCRIPTION

In the following description, various embodiments will be described. Forpurposes of explanation, specific configurations and details are setforth in order to provide a thorough understanding of the embodiments.However, it will also be apparent to one skilled in the art that theembodiments may be practiced without the specific details. Furthermore,well-known features may be omitted or simplified in order not to obscurethe embodiment being described.

Techniques described and suggested herein relate to the use of securelymaintained secret information in various authentication methods. Themethods may be used as a mechanism to control access to variousresources, such as data, physical items, real property, currency andothers. In an embodiment, a passcode (e.g., password) hash value (whichmay be referred to simply as a “hash”) is calculated using a hardwaresecret that, as discussed in more detail below, may be information towhich access, outside of a module configured to perform calculationswith the information, is extraordinarily difficult or even effectivelyimpossible. The calculated hash may be used to populate an entry in adatabase of passcode hashes that associates hashes of passcodes withcorresponding identities. When a passcode of an identity (e.g., user) isprovided for verification (i.e., when a purported passcode is provided),a reference hash (generally, “reference value”) of the passcode may becalculated based at least in part on the passcode and the hardwaresecret. The calculated reference hash may be compared to a storedpasscode hash in the database. If the calculated reference hash matchesthe stored passcode hash, the received passcode may be considered to beverified and a system relying on such verification may operateaccordingly.

The hardware secret, as noted, may be secret information that issecurely maintained and used for calculating password hashes. Thehardware secret may be configured such that the hardware secret has avalue from a set of values that has a specified size. For example, thesize of the set may be configured such that the cardinality of the setis larger than the cardinality of a set of possible passcode values.Generally, the size of the set may be selected to prevent cryptographicattacks. As an example, the size of the set may be selected so thatassumed amounts of processing resources (which may be based at least inpart on estimates of current or future capabilities) collectivelyworking to determine a passcode from a given hash of a passcode would,probabilistically speaking, be extremely unlikely to determine thepasscode in a specified reasonable amount of time, where the probabilitymay be a specified value set at some acceptable threshold. As anillustrative example, the size of the set may be such that allprocessing capacity on Earth, if collectively working to determine apasscode from a hash value, would have a probability of less than a0.0000000001 of determining the passcode in one hundred years. Ofcourse, the particular example values given are for illustration, andgenerally any size set may be used. In some embodiments, for example,the set of possible hardware secrets is chosen to have at least 2²⁵⁶members. In this manner, mere access to the information stored in adatabase of passcode hashes does not provide opportunity to determinepasscodes from hashes, thereby enabling unauthorized presentation of apasscode for the purpose of illegitimately gaining access to a resource.On the contrary, such a cryptographic attack is infeasible, even ifparallelization techniques are utilized.

Various embodiments of the present disclosure also provide foradditional security of passcodes. For example, as implied above, inembodiments where the size of the set of possible hardware secrets issufficiently large, cryptographic attacks are more likely to succeed byguessing the passcodes themselves since passcodes, relatively speaking,are from a much smaller space of possible values, especially whenconsidering that users often select passcodes with semantic meaning and,generally, passcodes that are easy to remember. To prevent such attackseven when an attacker has gained access to and control over the devicehaving the hardware secret, the device may be configured with particularperformance characteristics that render such attacks infeasible. As oneexample, a hardware secret may be used to ensure that a work factor(e.g., amount of time or number of operations needed to determine guessa passcode) is statistically large. For example, the hash of a passcodemay require iterative use of the hardware secret, possibly for thousandsor millions of operations. In this manner, each guess at a password mayrequire a number of operations (and a corresponding amount of time). Thework factor may be configured such that the computational work requiredto calculate a password hash is insignificant for authorized uses of asystem (e.g., a user providing a password to gain access to a resource),but significant for unauthorized uses (e.g., repeatedly guessingdifferent passwords). For example, calculations that take severalmilliseconds may be insignificant to a human user, but may causesignificant delay for cryptographic attacks requiring numerous passwordguesses.

As another example, a device using a hardware secret to calculatepasscode hashes may be configured to perform only a limited number ofoperations. Generally, such a device may be configured to operate inaccordance with one or more usage limits applicable to use of thehardware secret in the performance of operations. A usage limit may beor otherwise correspond to, for example, a limit (quota) on a number ofoperations that may be performed using the hardware secret. A usagelimit may also be or otherwise correspond to a limit on a rate on whicha device is able to perform operations using the hardware secret, suchas a limit on a number of passcode verifications and/or decryptionsperformable by the device in a specified amount of time (e.g. month). Adevice may be configured to operate in accordance with multiple usagelimits and/or types of usage limits. For example, a hardware device mayhave multiple hardware secrets, each with a corresponding usage limit,where each usage limit may be the same or where the usage limits maydiffer among the hardware secrets of the hardware device. Usage limitsmay be different from clock rates limits for processors of devicessubject to the usage limits. For example, a usage limit may cause adevice to be able to perform operations at a rate that is slower thanthe device is physically capable of in accordance with a current clockrate limit setting for its processor. In other words, a usage limit fora hardware secret of a device may be configured such that operationsusing a hardware secret must be performed at a rate that is slower thana processor of the device is currently capable of performing theoperations.

In some embodiments, the number of operations performable in accordancewith a usage limit is deterministically determined (e.g., set inprogramming logic). A device may, for instance, be configured to performself-destructive actions after performing a programmed number ofoperations. The limit may be probabilistically determined in someembodiments. For example, certain computing resources (e.g., computermemory) wears out and fails after a number of operations (e.g., writeoperations) where the number may not be consistent across devices.Algorithms for calculating passcode hashes may be configured to cause adevice to, statistically speaking, wear out after a certain number ofoperations. The number of operations, whether deterministically orprobabilistically set, may be configured such that, the device is ableto perform a specified sufficient number of operations (e.g., a numberof passcode verifications the device is expected to legitimately performduring its lifetime or during a specified amount of time). Cryptographicattacks involving password guessing, however, may require many morepassword verification attempts than the device is expected tolegitimately perform in a lifetime. Accordingly, the number ofoperations may also be set to cause a device to fail before acryptographic attack involving password guessing has more than somespecified probability of succeeding by guessing a correct passcode for agiven hash.

Other mechanisms may also be used to prevent successful cryptographicattacks, even with control over a device having a hardware secret usedto calculate password hashes. For example, processors may bedeliberately configured and/or selected to be, relatively speaking,slow. Slow processing capability may be insignificant to a human user,but slower speeds correlate with attacks that proceed slower and,therefore, require more time on average before successfully determininga passcode from a hash. Other techniques and combinations of techniquesmay also be used.

Generally, other variations are considered as being within the scope ofthe present disclosure. For example, in some embodiments, hardwaresecrets are used in one-time passcode/password (OTP) schemes. A securitytoken may be a device or programming module configured todeterministically generate passcodes based at least in part on a seedvalue (which may be referred to as a “seed”) and a time, which may be atime of passage since some reference time (e.g., token creation or Unixtime). At predefined times (or otherwise for multiple times during aduration of time), the token may generate a new passcode based at leastin part on the seed and the time. A passcode provisioning system may beconfigured to likewise deterministically calculate the same codes (e.g.,a finite number of codes that the token will produce), although inadvance. The codes may be provided to an OTP verification system whichmay then use a hardware secret to calculate, for the calculated codes,passcode hashes. The passcode hashes may be stored in a database used toverify passcodes provided using the token. In this manner, instead ofthe OTP verification system generating the codes itself forverification, the seed may be securely kept from the OTP verificationsystem, thereby reducing the likelihood that the seed may be accessedwithout authorization and that, as a result, the token 504 can becloned. In other words, the OTP verification system does not need theseed because it already has hash values of the codes it will need toverify. As a result, a system employing the techniques of the presentdisclosure is more secure than systems employing many conventionaltechniques.

FIG. 1 shows an illustrative example of an environment in which variousembodiments may be practiced. In the environment 100 illustrated in FIG.1, a user 102 communicates over a network 104 with a passcodeverification system 106, which may be implemented as a verificationserver that receives verification requests, generates responses to therequests and provides responses to the requests. The user maycommunicate with the passcode verification system 106 by way of one ormore customer devices and/or interfaces such as those described below.The network 104 may be any suitable communications network such as theInternet or another network discussed below or combination of networks.It should be noted that while the user 102 is shown as communicatingdirectly with the passcode verification system 106, communication withthe passcode verification system 106 may be indirect. For instance, thepasscode verification system 106 may be a backend system of anothersystem with which the user 102 communicates. Further, while FIG. 1 showscommunication with the passcode verification system 106 by way of anetwork 104, communication with the passcode verification system 106 mayoccur without a network 104. For instance, the user 102 may communicatewith the passcode verification system 106 via a local interface (e.g.,one or more user input devices) of a system on which the passcodeverification system 106 is implemented.

The user 102 may communicate with the passcode verification system 106for any purpose involving the use of passcodes. A passcode may beinformation usable to access one or more resources. An example passcodeis a password which comprises a string of one or more alphanumericcharacters which may be chosen by a user, perhaps in accordance with oneor more rules regarding length, complexity and the like. Another examplepasscode is a PIN. While passwords and PINs are used extensivelythroughout the present disclosure for the purpose of illustration, theterm passcode is intended to be interpreted broadly to cover other typesof information usable to access a resource which may or may not beinformation that a user may know. Example information includes biometricinformation, demographic information and/or, generally, any informationwhich may correspond to a user, possibly uniquely. Example uses forpasscodes include, but are not limited to, access control to data,causing the performance of one or more operations and/or generallyaccess to any resource including physical resources, such as money, inembodiments where the passcode verification system 106 is part of amoney dispensing system such as an ATM.

As illustrated in FIG. 1, in an embodiment the passcode verificationsystem utilizes a hardware secret 108. A hardware secret may be secretinformation maintained by a device such that there is no legitimate wayto access the hardware secret. For example, the hardware secret may beencoded in hardware of a hardware device that employs various securitymeasures. The hardware device for example may be tamper resistant,tamper evident and/or generally may employ mechanisms that preventphysical intrusion into the device to obtain the hardware secret. Inother words, the hardware secret may be maintained such, so as to beobtainable without physical intrusion into a device that has access tothe hardware secret, if such physical intrusion is even possible. Inother words, the hardware secret may be maintained such that anyprocessor external to the device is unable to execute code that allowsthe processor to obtain the hardware secret in an authorized manner.Accordingly, a hardware secret may be maintained by the device so as tobe programmatically unexportable (i.e., such that there is no legitimateway to programmatically cause (e.g., through an interface of the device)the device to provide the hardware secret). The hardware secret may bemaintained, for example, such that there is no request mechanism (e.g.,application programming interface (API) call) for causing hardware,storing the hardware secret, to reveal the hardware secret. As anexample, a device storing the hardware secret (e.g., cryptographicmodule) may be configured to lack an ability to provide a copy of someor all of its memory such that the copy includes the hardware secret. Itshould be noted however, that while hardware secrets, for which there isno legitimate way of obtaining the hardware secret, are used throughoutthe disclosure for the purpose of illustration, some hardware secretsmay be maintained, such that the hardware secret is obtainable through alimited number of authorized uses, which may require various securityprotocols to be employed and able to prevent unauthorized access to thehardware secret. Generally, a hardware secret is information (e.g., oneor more cryptographic keys) for which extraordinary measures must betaken to obtain the hardware secret, if it is possible at all to obtainthe hardware secret.

As illustrated in FIG. 1, the environment 100 includes a passcodedatabase 110 or, generally, persistent data storage for informationbased at least in part on passcodes. The passcode database 110 may be adata storage system with which the passcode verification system 106communicates for the purpose of storing hash values of passcodes. Thepasscode database 110, for example, may store hash values of passcodesfor multiple users 102 in association with identifiers for the users,thereby allowing for passcodes submitted by users to be verified. Thepasscode database 110 may be implemented in various ways. For example,the passcode database 110 and passcode verification system 106 may bedifferent computer systems that communicate with one another over anetwork. In other embodiments, the passcode database 110 is a localstorage devise of passcode verification system 106. Numerous variationsare also considered as being within the scope of the present disclosure,such as variations where the passcode verification system 106 includesboth a separate passcode database and a local cache of passcode hashes.

As illustrated in FIG. 1, hashes in the passcode database are generated,based at least in part, on a passcode and the hardware secret 108. Thepasscode verification system 106 may, for example, upon receipt of a newpasscode from a user 102 or generation of a new passcode for the user102, calculate a hash of the passcode, based at least in part, on thepasscode and the hardware secret. The hash of the passcode may becomputed in various ways in accordance with various embodiments.Generally, the hash of the passcode may be calculated, based at least inpart, on output of one or more one-way functions. Example one-wayfunctions include, but are not limited to secure hash functions, such asMD5, as those classified as secure hash algorithm two (SHA-2) such asSHA-224, SHA-256, SHA-384 and SHA 512. For example, the hash of thepasscodes may be or otherwise may be based at least in part on akeyed-hashed message authentication code (HMAC) such as HMAC_MD5,HMAC-SHA-2 (where HMAC-SHA-2 denotes HMAC using a SHA-2 function). Otherexample password hashes include password based key derivation functions(PBKDFs) such as PBKDF2 and Bcrypt. It should be noted that the term“one-way” is used in the practical sense and is not necessarily limitedto functions within the strict mathematical definition of one wayfunctions. Generally, as used herein, one-way functions are functionssatisfying one or more conditions on invertability. For example, the oneor more conditions may be that the probability of a random input,generating a given output, is within some bound specified as acceptableor, generally, is believed to be (e.g., as a result of experimentation)within some bound specified as acceptable. In some instances, a functionmay be considered one-way if there is no known formula or algorithm orfor the calculating the inverse.

Other functions and values, based at least in part on the output of thefunctions, are considered as being within the scope of the presentdisclosure. Generally, a hash of a passcode is intended to cover theoutput of any function that takes as input at least a passcode andanother value (e.g., hardware secret) and provides output that is atransformation of the passcode to another value. Further, the functionmay be configured to have an effect on the number of computationsrequired to calculate the function. For example, in some instances thefunction is configured as a composite function, where computation of thefunction requires the output of one function to be used as the input toanother function, possibly iteratively. The number of iterations of asub-process involved in calculating the value of a function may be atunable parameter. In this manner, the amount of computational resourcesmay be configured to avoid the speed at which brute force and otherattacks are able to verify password guesses.

The passcode verification system 106 may provide the passcode orinformation based thereupon to a cryptographic module of the passcodeverification system 106 that stores the hardware secret 108. Thecryptographic module may be a system configured to securely store andperform operations using one or more hardware secrets. The cryptographicmodule may be a locally attached device of a computing device, used toimplement the verification system 106, or a redundant node thereof ormay be a device accessible to the verification system 106 over anetwork. When implemented as a hardware device, either locally attachedor remotely accessible, the cryptographic module may also be referred toas a cryptographic hardware module. Example cryptographic modules arediscussed in more detail below. Upon receipt of the password orinformation based at least in part thereon, the cryptographic module maycalculate the hash based at least in part on the hardware secret andinformation provided from the passcode verification system. Thecryptographic module may provide the calculated hash to the passcodeverification system, which may then transmit the hash to the passcodedatabase for persistent storage.

As discussed in more detail below, when the user 102 provides apasscode, such as to authenticate or otherwise access one or moreservices, the user may provide the passcode to the passcode verificationsystem over the network 104. Various secure protocols, such as transportlayer security (TSL) and/or socket layer security (SSL), may be used totransfer the passcode from the user 102 to the passcode verificationsystem 106 to avoid sending the passcode over the network 104 incleartext (plaintext) form. Further, while the user providing a passcodeis used throughout for the purpose of illustration, the scope of thepresent disclosure is intended to cover additional embodiments where theinformation the user provides for authentication (authenticationinformation) is the passcode or is otherwise based at least in part onthe passcode. Example embodiments include those where a passcode inputby a user, is transformed before providing to a verification system and,similarly, before the verification system generates a hash forpersistent storage. Further, human operator users are depicted in thedrawings for illustration, passcodes may be provided by automatedsystems whether or not the passcodes were provided concurrently by theusers themselves.

The passcode verification system 106 may receive the passcode from theuser 102, decrypt if necessary, and provide the passcode to a modulehaving the hardware secret to cause the cryptographic module tocalculate a hash of the passcode using the hardware secret 108. A resultprovided from the cryptographic module may be compared by the passcodeverification system 106 with a stored hash 112 of the passcode in thepasscode database 110. If the calculated hash value and the stored hashvalue match, it may be considered that the user has successfullyvalidated the passcode (e.g., provided a correct passcode). One or moreactions corresponding to successful validation may be performed, such asby providing access to one or more resources.

FIG. 2 shows an illustrative example of an environment 200 in whichvarious embodiments may be practiced. In the environment 200, a user 202communicates with the system 204. The system 204 and, therefore, how theuser 202 communicates with the system 204 may vary in accordance withvarious embodiments. For example, the system 204 may provide access toinformation through a website and, as a result, communication mayinclude various ways of website navigation. As another example, thesystem 204 may be an ATM and, as a result, communication may includeinteraction with a local physical interface (e.g., keypad, touchscreen,card reader and/or near-screen buttons) of the ATM. As yet anotherexample, the system 204 may be a computing device usable to controlaccess to certain premises, such as through an automated mechanical gateor door. Generally, the system may be any suitable system for whichpasscodes are used for one more purposes, such as granting access tosomething for which access is obtainable (e.g., required) by providing acorrect passcode.

As noted, in an embodiment, the system 204 includes an interface 206 andthe interface 206 may vary as the system 204 varies in accordance withthe various embodiments. In some examples, the interface 206 is a webinterface and the user 202 communicates with the interface 206 over anetwork, such as the internet. Communication with the web interface mayoccur, for example, via a web browser or other application. In someembodiments, the user 202 interacts with the system 204 while ingeographic proximity with the system 204. For example, the system 204may be an ATM and the interface 206 may be a combination of inputdevices (e.g., keypad, near-screen buttons, touchscreen, card reader andthe like) and/or display devices that enable the user 202 to provideinput to the system 204. Similarly, the system 204 may be a mobiledevice, such as a tablet computing device and/or cellular telephone(smart phone) having a touchscreen, keyboard and/or other input deviceusable by the user 202 for providing input. Generally, the interface 206may be any collection of computing resources which may include inputdevices, display devices and/or generally devices that are able toreceive remotely and/or locally generated data into the system 204 forprocessing.

In an embodiment, the interface 206 enables communication with variouscomponents with system 204 to provide the user 202 access to a resource208. The resource 208 may be any resource by which correct presentationof a passcode is a prerequisite for access. Examples, as noted above,include money, data, physical items, services, real property and otherresources. Other examples include functions on a computing device (e.g.,mobile device, tablet device or personal computer). For instance, a usermay use an interface to enter a passcode to unlock a mobile device toaccess applications of the device, operating system functions and thelike. Until a passcode is entered, the device may offer a more limitedfunctionality. Of course, the various embodiments of the presentdisclosure are not limited to the specific resources explicitlydescribed herein but extend to other types of resources as well.

As noted above, the user 202 interacts with the interface 206 for thepurpose of accessing the resource 208. As illustrated by the lock symbolon the resource 208, the resource 208 may be protected by the systemfrom unauthorized access through one or more access control mechanisms.In order to do this, the interface 206 may be configured to require thatthe user 202 provide a passcode. The interface 206 may receive thepasscode from the user 202 and provide the passcode to a passcodeverification system 210. The passcode verification system 210 may be acomponent of the system 204, such as described above in connection withFIG. 1. The passcode verification system, for example, may beimplemented as a separate computing device, a programming module on acomputing device, a hardware module on a computing device and/or onother ways. The passcode verification system 210, may have access to apasscode database 212, which may store hashes of passcodes. As discussedabove in connection with FIG. 1, the passcodes may be generated based,at least in part, on a hardware secret, where the hardware secret may bemaintained by the passcode verification system 210 or by another entitywith which the passcode verification system 210 is able to communicate.

As noted above, when the user 202 presents a passcode through theinterface 206, the passcode verification system 210 may generate, orcause to have generated, a hash of the passcode based at least in parton the passcode and a hardware secret and then compare the generatedhash with a hash stored in the passcode database 212. If the generatedhash and the stored hash match, the user 202 may be provided access tothe resource 208. If, however, the generated hash and the stored hash donot match, the user may be denied access to the resource 208, at leastuntil the user is able to provide a correct passcode or otherwiseauthenticate.

FIG. 3 shows an illustrative example of a process 300 which may be usedto verify a passcode received from a user, such as described above. Theprocess 300 may be performed by any suitable system or componentthereof, such as by a passcode verification system described above. Inan embodiment, the process 300 includes receiving 302 a passcode. Thepasscode may be received in various ways in accordance with variousembodiments. As another example, the passcode may be received as aresult of a user having input the passcode one or more input devices ofa system with which the user interacts. As another example, the passcodemay be received over a network, perhaps through one or more components,such as a webserver and/or application server, such as described below.Generally, the passcode may be received 302 in any manner.

In an embodiment, the process 300 includes calculating 304 a hash of thepasscode. Calculating the hash of the passcode may be performed byinputting the passcode and a hardware secret and, in some embodiments,other information, such as a salt into a hash or other function, such asdescribed above. Generally, the hash of the passcode may be calculatedin any way. Further, while various embodiments of the present disclosureuse hashes and hash function for the purpose of illustration, otherfunctions not necessarily commonly categorized as hash functions may beused. For example, as noted, generally any type of one-way function maybe used to generate a value based, at least in part, on the passcode anda hardware secret.

In an embodiment, the process 300 includes looking up 306 a stored hashof the passcode. The stored hash of the passcode may be stored in memoryof a computer system, such as in volatile or nonvolatile memory of adata storage device locally attached to the system performing theprocess 300 or remotely accessible to the system performing the process300. Looking up 306 the stored hash may also include querying a local orremote database. It should be noted that while FIG. 3 illustratescalculating the hash of the passcode and looking the stored hash in aparticular order, as other operations described herein, variousembodiments of the present disclosure are not necessarily limited to theorder in which the operations are illustrated. For example, in someembodiments the stored hash may be looked up before the hash of thepasscode is calculated or the look up and the calculation may beperformed in parallel. Generally, the order of operations discussedherein are not necessarily performed in the order illustrated unlessexplicitly stated otherwise or otherwise clear from context. Further,while particular operations on specific data (e.g., passcodes, hardwaresecrets, salts and the like) are used for the purpose of illustration,such operations may more generally be based in part on such data. Theperformance of additional operations not described explicitly herein isalso considered as being within the scope of the present disclosure.

In an embodiment, the process 300 includes determining 308 whether thecalculated hash matches the stored hash. For example, by determiningwhether the calculated hash and stored hash are equal or otherwisematch. If it is determined 308 that the calculated hash matches thestored hash, the process 300 may include enabling 310 access to aresource. As noted above, the resource may vary widely in accordancewith various embodiments and enabling access may accordingly vary. Forexample, enabling access may include the transmission of one or moresignals (e.g., messages) that indicate to another component of a system(e.g., server, operating system, automated mechanical device (e.g.,lock), application and/or other possible components) to allow access. Asan example, enabling access to the resource may include transmitting oneor more signals that enables an application on an ATM to allow a user toobtain money from the ATM when the process 300 is performed as part ofan access control mechanism for money stored in the ATM. As yet anotherexample, enabling access to the resource may include transmitting one ormore signals that, when received by an operating system process of adevice, cause the operating system to provide additional functionality.Other examples are also considered as being within the scope of thepresent disclosure.

Referring back to FIG. 3, if it is determined 308 that the calculatedhash does not match the stored hash, the process 300 may include taking312 one or more actions corresponding to failed passcode verification.The one or more actions may include, for example, transmitting one ormore signals causing access to the resource to be denied or simply nottransmitting signals that, if transmitted, would enable access. Otheroperations, such as providing a message indicating that the passcode isincorrect may also be performed. In addition, various embodiments of thepresent disclosure may be used in conjunction with other access controlmechanisms and the one or more actions corresponding to the failedpasscode verification may also involve other access control mechanisms.For instance, in some embodiments a limited number of failed passcodeattempts are allowed before an adverse event occurs. The adverse eventmay include, for example, a lockout (e.g., inability to try anotherpasscode) for a predetermined amount of time, destruction of data (e.g.by erasing), and/or generally some type of adverse consequence whicheither renders the resource inaccessible, temporarily or permanently, orwhich makes the resource more difficult to access by the user, such asby requirements for additional authentication operations. In someembodiments, accordingly, the one or more actions corresponding to afailed passcode verification may include, for instance, updating acounter of failed passcode attempts. If the counter has already reacheda threshold, the one or more actions may include causing one or moreadverse events to occur. Other actions considered as being within thescope of disclosure include, but are not limited to, recording a failedpasscode attempt, providing notification of a failed passcode attempt,causing a delay before another passcode attempt is permitted and/orother actions.

While FIG. 3 shows an illustrative example of a process for verifying apasscode, other processes are considered as being within the scope ofthe present disclosure. For example, processes in accordance with thesecure remote passcode protocol (SRP) and variations thereof areconsidered as being within the scope of the present disclosure.Generally, various techniques described herein may be adapted to variousways of performing passcode verification.

FIG. 4 shows an illustrative example of a process 400 which may beperformed in order to generate a passcode hash in accordance with anembodiment. The process 400 may be performed by any suitable system orcomponent therein. For example, the process 400 may be performed bypassword verifier having access to a local or remote cryptographicmodule having a hardware secret, such as described above. The process400 may be performed in various contexts. For example, the process 400may be performed to populate a passcode database when a new passcode isreceived from, generated for or otherwise obtained for a user. Theprocess 400 may also be performed in order to verify a passcode providedby a user. In an embodiment, the process 400 includes obtaining 402 apasscode. The passcode may be obtained 402 in various ways in accordancewith various embodiments. For example, the passcode may be obtainedthrough internal communications within a computing device that hasreceived or otherwise obtained the passcode. As another example, whenthe passcode may be obtained 402 over a network. Generally, the passcodemay be obtained in various ways in accordance with various embodimentsand, in general, the various contexts in which the process 400 isperformed.

In an embodiment, the process includes providing 404 the obtainedpasscode to a cryptographic module having a hardware secret where thehardware secret may be described as above. Providing 404 the obtainedpasscode may be performed in various ways depending on the relationshipbetween the cryptographic module and the system performing the process400. For example, if the cryptographic module is an internal hardwaremodule of the system performing the process 400, providing 404 thepasscode may be performed by making a local device-level call to thecryptographic module. As another example, if the cryptographic module isremotely accessible over a network to the system performing the process400, appropriately formatted network communications may be used toprovide the passcode to the cryptographic module. In some embodiments,the cryptographic module is operated by a cryptography service with aweb service interface and providing 404 the passcode may be performedvia an appropriately configured web service API call. Other variationsare also considered as being within the scope of the present disclosure.

A result may be obtained 406 from the cryptographic module. The resultmay be one or more values generated by the cryptographic module based,at least in part, on the information provided to the cryptographicmodule and the hardware secret. A determination may be made 408 whetherthere are enough iterations (i.e., if enough iterations of aniteratively performed calculation involving the passcode and hardwaresecret have been performed). For example, the cryptographic module maybe configured to input information (e.g., passcode or results from aprevious result received from the cryptographic module) from the systemperforming the process 400 into a function (which may itself beiterative within the cryptographic module), such as described above. Fora performance of the process 400, each time the system performing theprocess 400 provides information involving the obtained 402 passcode tothe cryptographic module for input with the hardware secret into thefunction may be considered an iteration for the purpose of the process400, although other definitions of iteration may be used. Whether enoughiterations have been performed may be determined 408 by comparing acount of iterations against a preprogrammed parameter corresponding to anumber of iterations. The parameter may, in some embodiments, beconfigurable, e.g., by a human operator having administrative or otheraccess sufficient for setting the parameter. The number of iterations tobe performed may be set based at least in part on physical capabilitiesof the cryptographic module and/or the system performing the process400. For example, higher numbers may be set to cause the time to verifya password to exceed a specified minimum time, thereby impeding thespeed at which unauthorized attempts at password verification are ableto be performed.

If it is determined 408 that a sufficient number of iterations have beenperformed, the result from the cryptographic module or information basedat least upon the result from the cryptographic module may be provided410. The manner in which the result is provided may vary in accordancewith the various contexts in which the process is performed. Forinstance, providing 410 the result may involve internal devicecommunications encoding the result, network communications encoding theresult and/or other operations.

If, however, it is determined 408 that an insufficient number ofiterations have been performed then a result from the cryptographicmodule may be provided 412 to the cryptographic module with the hardwaresecret. As noted, the result may be used by the cryptographic module asinput into a one-way function in order to iterate the process andgenerate another value. This process of providing the cryptographicmodule a result obtained from the cryptographic module (or informationbased at least upon a result received from the cryptographic module) maybe repeated until it is determined 408 that a sufficient number ofiterations have been performed. Once determined 408 that there areenough iterations as noted above the result may be provided, such asdescribed above.

In this manner, calculating a hash of a passcode may require numerouscalls to a module with a hardware secret and generally may requirenumerous operations thereby making the calculation relatively slow. Inthis manner, unauthorized attempts to guess the passcode may requirecomputer resource usage which, in the context of normal passcodeverification operations, such as when a user supplies a passcode toobtain access to a system, is insignificant, but for which cryptographicattacks which involve multiple guesses of the passcode is significant.

It should be noted that variations of the process 400 are considered asbeing within the scope of the present disclosure. For example, theprocess 400 as illustrated is configured to require multiple calls to acryptographic module in order to ultimately determine the hash of apasscode based at least in part on the passcode and a hardware secret.Other variations include those where the passcode is provided to thecryptographic module and the cryptographic module performs a specifiednumber of iterations before providing a result back. Other variationsincluding those where the cryptographic module performs severaliterations to provide a result which is then provided back to thecryptographic module for more iterations are considered as being withinthe scope of the present disclosure. In addition, while FIG. 4illustrates certain operations, as with all processes described herein,additional operations may also be performed. For instance, as noted, aresult from a cryptographic module may be transformed (e.g., through aone-way function) before being provided back to the cryptographicmodule. Generally, the particular algorithm illustrated in FIG. 4 isillustrative in nature and a large number of variations that employ thesame principles are considered as being within the scope of the presentdisclosure.

Various embodiments of the present disclosure may also be used inconnection within one time passcode/passcode (OTP) verificationssystems. FIG. 5, accordingly, shows an illustrative example of anenvironment 500 in which various embodiments may be practiced. Asillustrated in FIG. 5, a user 502 may interact with an interface 506 inorder to access a resource 508, such as described above. As part of theinteraction with the interface 506 the user 502 may provide a one-timepasscode which may be a passcode that is valid for only one sessiontransaction period of time or otherwise. The user may have access to asecurity token 504, that may be a hardware device (hard token) orprogramming module (soft token) on a computer system configured togenerate at various time intervals a new one-time passcode based, atleast in part, on a seed which may be, for example, a random value inputinto a one-time passcode generation algorithm. SecurID tokens producedby RSA Security LLC are illustrative examples of such tokens, althoughembodiments of the present disclosure are not limited to such tokens.

The user 502 may obtain a one-time passcode provided to the interface506 for access to the resource 508. In order to control access to theresource 508 interface, it may communicate with a one-time passcode(OTP) verification system 510, which may operate to verify a passcode,such as described above. In particular a passcode provided by the user503 through the interface 506 may be provided to the OTP verificationsystem 510. The OTP verification system 510 may then obtain a hash ofthe received passcode and compare the calculated hash with a stored hashof the passcode to determine whether or not the passcode is valid. Asillustrated, in some embodiments, the OTP verification system 510 hasaccess to a passcode database 512, which stores a set of passcodehashes, such as described above, that correspond to passcodes that havebeen and/or will be generated by the security token of the user 502.

For example, the security token may generate one-time passcodes inaccordance with a deterministic algorithm. Information stored in thepasscode database 512 may include a hash of every passcode that will begenerated by the security token over a period of time. For the user 502for example, the passcode database 512 may store a hash of specifiednumber of passcodes that will be generated by the security token uponthe security tokens initialization. As another example the passcodedatabase 512 may store a hash of each passcode that the security tokenwill generate over a specified amount of time such as a month, a year,several years, a predetermined life of the token 504 or the like.

In order to store hashes of multiple passcodes that will be generated bya security token of the user 502 the passcode database 512 may receivethe passcodes from a passcode provisioning system 514. The passcodeprovisioning system may be a system (e.g., computing device orprogramming module operating on a computing device) that is configuredto deterministically generate the codes that the token 504 will generateover a time period. For example, the passcode provisioning system mayhave access to a seed 518, shared by the token 504, that is used by thetoken 504 in generating passcodes and may use the seed 518 to generate aset of passcodes that will be generated by the token 504 over time. Inan embodiment, the passcode provisioning system 514 generates the codesand provides the generated codes 520 (e.g., over a network or via aphysical provisioning device such as a universal serial bus (USB)dongle) to the OTP verification system 510. The OTP verification mayreceive the passcodes, use a hardware secret 516, such as describedabove, to generate hash values of the passcodes, and store thepasscodes. The plaintext passcodes may then be deleted. In this manner,as described in more detail below, the OTP verification system is ableto verify passcodes without the seed used by the token 504, therebyreducing the chance that unauthorized access to the seed will occur,thereby causing a security breach.

The passcodes may be encoded in various data structures, such as lists,Bloom filters, tables that associate codes with timestamps and/orotherwise. In some embodiments, the passcode provisioning systemprovides the passcodes in the data structure and the OTP verificationsystem modifies the values in the data structure using the hardwaresecret (e.g., by calculating the hash values of the OTP codes in theprovided data structure). In other embodiments, the passcodeprovisioning system provides the passcodes (e.g., in a list or table)and the OTP verification system generates the data structure that itwill use to verify passcodes. Other variations are considered as beingwithin the scope of the present disclosure. For example, the OTPverification system 510 and passcode provisioning system 514 may sharethe same hardware secret, thereby enabling the passcode provisioningsystem 514 to provide the passcode hashes to the OTP verification systemwithout requiring the OTP verification system to calculate the hashesitself for populating the passcode database 512.

The OTP verification system may utilize whatever data structure thepasscodes are encoded in to determine whether a passcode is valid. Forexample, upon receipt of a passcode from the user 502 (e.g., pursuant touser-input of the user or input from the token 504 itself), the OTPverification system may use it's hardware secret 516 to calculate a hashof the received passcode and check whether the calculated hash matches astored hash in the passcode database 512, such as described above.

Because the passcode database 512 may store multiple passcode hashes fora single identity (e.g., the user 502, which may be one of many usersfor whom sets of passcodes are stored in the passcode database 512), theway in which passcodes are verified may vary among the variousembodiments. For example, in some embodiments, a bloom filter may beused to make a determination whether a passcode is correct by using acalculated hash of a received passcode to determine whether thecalculated hash appears in the passcode database 512. As anotherexample, a table may associate hashes of passcodes with correspondingtime intervals, each of which may be marked by a single time stamp. Whena passcode is received for verification at a particular time, the OTPverification system may check whether a calculated hash of the receivedpasscode matches that which is stored for a corresponding time interval.As yet another example, passcode hashes for a user stored in thepasscode database 512 may be enumerated. When a passcode is received forverification, the OTP verification system 510 may use the hardwaresecret 516 to calculate a hash of the received passcode and query thepasscode database 512 to determine if the calculated hash is in thedatabase 512. If found, in addition to causing one or more operations tobe performed corresponding to the passcode being verified, hashes lowerin the enumeration may be electronically marked (e.g., stored inassociation with an indication of invalidity) as invalid, if notelectronically marked as such already. In this manner, passcodes thatthe token 504 would have calculated in the past are no longer usable.Other variations and combinations of techniques are considered as beingwithin the scope of the present disclosure.

FIG. 6 shows an illustrative example of a process 600 for provisioning apasscode database with hashes of passcodes that will be generated by asecurity token in accordance with various embodiments. The process 600may be performed by any suitable system, such as by a passcodeprovisioning system 514 described above in connection with FIG. 5 or asuitable component thereof. In the embodiment, the process 600 includesobtaining 602 a seed. The seed may be obtained in any suitable manner.For example, the seed may be obtained as output of a random numbergenerator. Generally, the seed may be obtained in any suitable way andthe seed may match a seed provided to a token, such as the token 504discussed above in connection with FIG. 5.

A hardware secret may then be used 604 to generate a first OTP code.Generating an OTP code may be performed in various ways in accordancewith various embodiments. For example, the hardware secret, the seed anda time may be input into a function (e.g., hash function) whosealgorithm for calculation, which may be iterative, is programmed intothe system performing the process 600. Once the hardware secret has beenused to generate the first OTP code, the generated first OTP code may bestored 606. For example, the generated OTP code may be stored in a file,database or otherwise in volatile memory and/or nonvolatile memory.

A determination may be made 608 whether enough OTP codes have beengenerated, where the number considered enough may be preprogrammedand/or configurable. If determined 608 that an insufficient number ofOTP codes have been generated, the process 600 may include using 604 thehardware secret to generate and store 606 the next OTP code. The nextOTP code, in some embodiments, is based at least in part on a previouslygenerated OTP code (e.g., the immediately preceding generated OTP code),although in other embodiments, each OTP code may be independentlygenerated. Generation and storage of OTP codes may repeat until it isdetermined 608 that a sufficient number of OTP codes have beengenerated. Once determined 608 that a sufficient number of OTP codeshave been generated, the process 600 may include generating 610 a datastructure encoding the stored OTP codes. The data structure may beconfigured in various ways in accordance with various embodiments, suchas described above. The data structure may be provided 612 to one ormore OTP verifications where, if multiple OTP verifications, each OTPverification system may be a member of a redundant fleet, each with adifferent hardware secret. An OTP verification may reconfigure and usethe provided 612 passcodes, such as described above.

FIG. 7 is an illustrative, simplified block diagram of an example devicesystem 700 that may be used to practice at least one embodiment of thepresent disclosure. In various embodiments, the device system 700 may beused to implement any of the systems illustrated herein and describedabove. For example, the device system 700 may be used to generate data(e.g., passcode hashes) for populating a database and/or to verifypasscodes. As shown in FIG. 7, the device 700 may include one or moreprocessors 702 that may be configured to communicate with and areoperatively coupled to a number of peripheral subsystems via a bussubsystem 704. These peripheral subsystems may include a storagesubsystem 706, comprising a memory subsystem 708 and a file storagesubsystem 710, one or more user interface input devices 712, one or moreuser interface output devices 714, a network interface subsystem 716, acryptographic module 724, comprising a memory subsystem 730 and one ormore cryptographic processors 732.

The bus subsystem 704 may provide a mechanism for enabling the variouscomponents and subsystems of device system 700 to communicate with eachother as intended. Although the bus subsystem 704 is shown schematicallyas a single bus, alternative embodiments of the bus subsystem mayutilize multiple busses.

The network interface subsystem 716 may provide an interface to otherdevice systems and networks. The network interface subsystem 716 mayserve as an interface for receiving data from and transmitting data toother systems from the device system 700. For example, the networkinterface subsystem 716 may enable receipt of passcodes and provideinformation indicating whether received passcodes are authentic (e.g.,correct). For example, a verification request may be provided to thedevice 700 and the network interface 716 may enable both the receivedand a response to be provided. The network interface subsystem 716 mayalso facilitate the receipt and/or transmission of data on othernetworks, such as an organizations intranet and/or other networksdescribed below.

The user interface input devices 712 may include one or more buttons, akeyboard, keypad, pointing devices, such as an integrated mouse,trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, afingerprint scanner, a retinal scanner, a touchscreen incorporated intoa display, audio input devices, such as voice recognition systems,microphones and other types of input devices. Further, in someembodiments, input devices may include devices usable to obtaininformation from other devices. Input devices may include, for instance,magnetic or other card readers, one or more USB interfaces, near fieldcommunications (NFC) devices/interfaces and other devices/interfacesusable to obtain data from other devices. In general, use of the term“input device” is intended to include all possible types of devices andmechanisms for inputting information to the device system 700.

User interface output devices 714, if any, may include a displaysubsystem, a printer or non-visual displays, such as audio outputdevices, etc. The display subsystem may be a cathode ray tube (CRT), aflat-panel device, such as a liquid crystal display (LCD), lightemitting diode (LED) display, or a projection or other display device.In general, use of the term “output device” is intended to include allpossible types of devices and mechanisms for outputting information fromthe device system 700. The output device(s) 714 may be used, forexample, to present user interfaces to facilitate user interaction withapplications performing processes described herein and variationstherein, when such interaction may be appropriate. While a device 700with user interface output devices is used for the purpose ofillustration, it should be noted that the device 700 may operate withoutan output device, such as when the device 700 is operated in a serverrack and, during typical operation, an output device is not needed.

The storage subsystem 706 may provide a computer-readable storage mediumfor storing the basic programming and data constructs that may providethe functionality of at least one embodiment of the present disclosure.The applications (programs, code modules (i.e., programming modules),instructions) that, when executed by one or more processors, may providethe functionality of one or more embodiments of the present disclosure,may be stored in the storage subsystem 706. These application modules orinstructions may be executed by the one or more processors 702. Thestorage subsystem 706 may additionally provide a repository for storingdata used in accordance with the present disclosure. The storagesubsystem 706 may comprise a memory subsystem 708 and a file/diskstorage subsystem 710.

The cryptographic module 724, which may be a trusted platform module,includes a memory subsystem 730, including a main random access memory(RAM) 728 for storage of instructions and data during program executionand a read only memory (ROM) 726, in which fixed cryptographicinformation may be stored, such as a hardware secret. The device 700 mayalso store keys in RAM 728 and/or processor registers for temporarycryptographic processing. The cryptographic information stored in memorymay be used in combination with cryptographic information (e.g.,passcode and/or information based at least in part thereon) obtained viathe network interface 716 and/or one or more of the user interface inputdevices 712. The one or more cryptographic processors may be used toperform cryptographic operations in the device and may include a randomnumber generator, SHA-2 or other hash generator and anencryption-decryption-signature engine. Generally, one or morecomponents of the cryptographic module 724 may be configured tocollectively perform various operations used in calculating hashes ofpasscodes, such as described above.

As noted above, in various embodiments of the present disclosure,hardware secrets are securely stored within the cryptographic module724. In some embodiments, the cryptographic module is implemented as ormay contain a physically unclonable function (PUF), which is a functionimplemented in physical hardware to use one or more hardware secretsthat are based at least in part on physical characteristics of the PUF.As a result, any attempt to obtain a hardware secret may requirephysical intrusion into the PUF and physical intrusion may alter thephysical characteristics of the PUF, thereby destroying the hardwaresecret. Example PUFs that may be used include PUFs usingexplicitly-introduced randomness, optical PUFs, coating PUFs, PUFs usingintrinsic randomness, delay PUFs, static random access memory (SRAM)PUFs, butterfly PUFs, bistable ring PUFs, magnetic PUFs, metalresistance PUFs and/or other devices whose physical characteristicsencode information usable as or for a hardware secret.

In addition, the cryptographic module 724 may be configured to havecertain speed and/or degradation characteristics. For example, theprocessing capabilities of the cryptographic module 724 may beconfigured to be slow relative to other processing capabilities, such asthose available in commodity processing devices. In some embodiments,for instance, it may be desirable to limit the speed at which the device700 is able to calculate hashes since, in authorized uses (e.g.,password verification), slow processing (e.g., a delay of millisecondsrelative to other processors available) may be insignificant to atypical authorized user who submits a password relatively infrequently(e.g., once per session), but very significant to an unauthorized user,such as someone who has stolen the device 700 and information in apasscode database and is using the device 700 to try to determinepasswords from stored hash values.

Degradation characteristics may be used to limit the number ofoperations that the device 700 is physically able to perform. Forinstance, reading and/or writing to certain types of memory (e.g., flashmemory or dynamic random-access memory (DRAM)) can cause the memory tobecome unusable over time through gradual depletion caused by readand/or write operations. The probability that a portion memory willbecome unusable after a number of operations may follow a probabilitydistribution which may be determined through experimentation.Accordingly, the device 700 may be configured to perform a specifiednumber of reads and/or writes to memory for each passcode verification.Calculation of a hash of a passcode may be programmed to require readsand/or writes to the memory. Further, the device 700 may be configuredto avoid performing refresh cycles for the memory that are typicallyperformed to slow the depletion of the memory.

The specified number may be selected such that, according to theprobability distribution, the probability of the memory becomingunusable exceeds some threshold (e.g., 0.99) after a specified number ofverifications (e.g., the expected number of verifications to berequested over an expected lifetime of the device 700 or a multiplethereof greater than one). Similarly, the specified number of readsand/or writes may be configured such that the probability of the deviceceasing to function at some desired number of passcode verificationremains within an acceptable bound (e.g., 0.01). In this manner, thedevice 700 can be configured to, as a matter of probability, functionproperly over some expected number of verifications and/or time periodwhen used in an authorized manner (e.g., passcode verification usingauthorized channels), yet cease to function when used in an unauthorizedmanner (e.g., by attempting to determine a passcode from a hash of apasscode, which, probabilistically, will require more verifications thanthe device 700 is able to perform). Additional techniques may beutilized to limit the number of operations performed. For example, insome data storage devices, read operations cause degradation of memoryand, to prevent degradation, the data storage devices follow readoperations with a refresh operation where the data is rewritten. Devicesutilizing the various techniques may be configured to avoid performanceof operations configured to refresh memory and, generally, to delaydegradation of memory to allow for limits to be reached sooner.

Other variations are also considered as being within the scope of thepresent disclosure. For example, in the above illustrative examples,stored passcode hashes are generated and verified symmetrically (usingthe same hardware secret). In some embodiments, however, a persistentlystored passcode hash may be generated using one secret and verifiedusing another secret. In some examples, for instance, the hardwaresecret may be a private key of a public-private key pair for anasymmetric cryptographic algorithm. A hash value may be calculated andpersistently stored based at least in part on a public key of thepublic-private key pair, where the public key is not maintained as ahardware secret. Further while hash values are used throughout for thepurpose of illustration, other values that are not necessarilyclassified as hash values may be used. For example, general output ofone-way functions may be used whether or not the functions areclassified as hash functions. As another example, output of invertiblefunctions may be used. In some examples, for instance, a hardware secretmay be used to generate an encrypted passcode (or encrypted data basedat least in part on the passcode). When a passcode is received, thehardware secret may be encrypted to determine whether the encryptedpasscode matches a stored encrypted passcode. Alternatively, a storedencrypted passcode may be decrypted using the hardware secret todetermine whether the decrypted passcode matches a received passcode.

Referring back to FIG. 7, as noted, numerous variations are consideredas being within the scope of the present disclosure. For example,devices that operate using hardware secrets may vary in accordance withvarious embodiments. Some devices may include, for instance morecomponents than illustrated and/or described above. Some may includefewer components. As an illustrative example, a device 700 may beimplemented as a smart card, chip card, subscriber identity module, orintegrated circuit card. Accordingly, in some embodiments, the device700 lacks its own power source and is able to perform operations usingpower supplied from another device, which may be a device requestingcryptographic operations through an interface of the device 700.

Also, as noted above, devices 700 may be implemented to have variousperformance limitations to restrict the number of operations that may beperformed during an amount of time and/or the number of operations of acertain type that may be performed and/or in other ways. In someembodiments, limitations are programmatically enforced. A device 700 maybe configured to perform only a certain number of passcode verificationsper an amount of time. Such configuration may be implemented byexplicitly programmed limitations on the number of operations or inother ways that effectively limit the number of operations, such as byenforcing a certain processing speed for one or more processors of thedevice 700. Further, a device 700 may be configured to only perform alimited number of passcode verifications before becoming inoperable toverify passcodes. In some embodiments, the limit is programmaticallyenforced. The device 700 may, for example, be configured to simply ceaseperforming passcode verifications after a certain number ofverifications. In some examples, the device 700 is configured with theability to perform physically destructive operations that cause thedevice 700 to become physically unable to perform passcodeverifications. The device may, for instance, be configured withcircuitry that destroys one or more hardware secrets. The hardwaresecret may be, for instance, stored in programmable ROM (PROM) andoverwritten after a specified number of passcode verifications. Asanother example, circuitry enabling use of a hardware secret may beequipped with one or more fuses. Fuses may be burned to render ahardware secret unusable to be used for passcode verification. Fuses, insome embodiments, are resettable while, in other embodiments, fuses arenot resettable. As yet another example, circuitry in the device may beconfigured to pass a high voltage charge to a cryptographic processor,thereby rendering the cryptographic processor inoperable to utilize ahardware secret needed to verify passcodes. Other variations areincluded in the scope of the present disclosure including, but notlimited to, the use of thermal energy (e.g., extra thermal energyapplied or by a lack of cooling, such as by causing a cooling fan tobecome inoperable) to destroy and/or deplete one or more hardwaresecrets and, generally, any manner by which physical destruction of thehardware secret is achievable.

Turning to FIG. 8, an illustrative example of a process 800 forenforcing a limit on a number of passcode operations that a device canbe performed in accordance with at least one embodiment. The process 800may be performed by any suitable device, such as a device 700 discussedabove in connection with FIG. 7. As illustrated, the process 800includes receiving 802 a passcode verification request, which may bereceived in any manner and in accordance with the capabilities of theparticular device performing the process 800. For example, the requestmay be received in accordance with any communication protocol that thedevice is configured to communicate in accordance with. A passcodeverification process, such as described above and which may include useof a hardware secret, as above, may then be performed 804 as a result ofreceiving the passcode verification request. Upon performance of thepasscode verification process 804 (or prior thereto), the process 800may include updating a counter that indicates how many times a passcodeverification process has been performed since a reference time, whichmay be since initialization of a device performing the process 800 orfrom another reference time, such as since a time when a deviceperforming the process 800 has been refreshed. Updating the counter maybe performed, for instance, by incrementing a counter value. In someembodiments, the counter value is stored in the same memory bank as ahardware secret for which the counter is incremented. In this manner,attempts to physically intrude into the memory to reset the counter havethe result of destroying the hardware secret, thereby rendering thedevice performing the process 800 unable to perform additionaloperations using the hardware secret.

A determination may be made 808 whether a limit for the counter has beenreached, whether the limit may correspond to a number of operations thedevice performing the process 800 has been configured to perform. If itis determined 808 that the limit has not been reached, the process 800may proceed as discussed above as passcode verification requests arereceived 802. If, however, it has been determined 808 that the limit hasbeen reached, the process 800 may include performing 810 a processcorresponding to having reached the limit. The process corresponding tothe reached limit may include performing one or more operations thatrender the device performing the process 800 to be inoperable to performthe passcode verification process, permanently or, in some embodiments,for an amount of time when one or more other actions render the deviceonce again operable to verify passcodes. As discussed above, the processmay include performing one or more operations that render the deviceprogrammatically unable to perform passcode verification requests (e.g.,become configured to deny requests despite having access to a hardwaresecret needed to perform passcode verifications). As another example,the device may perform one or more self-destructive operations thatrender the device unable to perform passcode operations which mayinclude destruction to circuitry needed to perform passcode verificationand/or a hardware circuit.

As noted, numerous variations for enforcing performance limits for adevice performing passcode verifications are considered as being withinthe scope of the present disclosure. FIG. 9, for example, shows anillustrative example of a process 900 for enforcing a limit on thenumber of passcode verifications that are performable by a deviceperforming the process 900 which may be, for example, the device 700discussed above in connection with FIG. 7. The process 900, as discussedin more detail below, enforces a limit that is not explicitly programmedinto the device performing the process 900. Instead, in thisillustrative example, a limit is enforced using stochastic processes. Inan embodiment, the process 900 includes receiving 902 a passcodeverification request and performing 904 a passcode verification process,such as described above. A random number (or other value) then may begenerated 906, using a suitable random number generator. As used herein,the phrase random number generator is intended to encompasspseudo-random number generators and, as a result, a random number mayalso be a pseudo-random number.

A determination may be made 908 whether the generated 906 random numbersatisfies one or more conditions. The one or more conditions may beconfigured such that the probability of the random number satisfying thecondition(s) is within a specified range (which may be a range with zerolength, such as when the probability is known exactly). The condition(s)may be configured, for instance, such that that probability ofperforming N operations (N a positive integer) without the condition(s)being satisfied is above a threshold value. As an illustrative example,the random number may be generated within a particular range and the oneor more conditions may be a single condition that the random number is aparticular value within the range. As another example, the conditionsmay be that a random number be equivalent to a particular number moduloM, where M is a positive integer. As yet another example, the conditionsmay be the random number have a specified number of leading or trailingzeros. Other conditions are also considered as being within the scope ofthe present disclosure.

If determined 908 that the number satisfies the one or more conditions,the process 900 may repeat as described above as passcode verificationrequests are received 902. If, however, it is determined 908 that thenumber satisfies the one or more conditions, the process 900 may includeperforming 910 a process corresponding to the number satisfying the oneor more conditions, which may be the process corresponding to thereached limit described above in connection with FIG. 8.

Variations of the processes 800 and 900 are considered as being withinthe scope of the present disclosure. For example, operations of theprocesses 800 and 900 may be combined. In some embodiments, for example,instead of rendering a device inoperable to perform passcodeverifications upon a random number satisfying one or more conditions, acounter may be updated when the number satisfies the one or moreconditions. When the counter reaches a limit, the device may becomeinoperable to perform passcode verifications. In this manner, there is alower probability that the device will become inoperable after arelatively few number of passcode verifications since each time a randomnumber satisfies the one or more conditions, the counter is updatedinstead of causing the device to become inoperable. Thus, in the eventthe conditions are satisfied with a few number of passcodeverifications, the device still remains operable.

FIG. 10 shows an illustrative example of another process 1000 that maybe used to enforce limits on passcode verifications. In an embodiment, adevice performing the process 1000 (which may be the device 700described above in connection with FIG. 7) is configured with fusesincorporated into its circuitry, such as through use of PROM, fieldprogrammable read-only memory (FPROM) or one-time programmablenon-volatile memory (OTP NVM). In an embodiment, the process 1000includes receiving 1002 a passcode verification request and performing1004 a passcode verification process, such as described above. Further,after, during, or prior to performing 1004 the passcode verificationprocess, the process 1000 may include burning 1006 a fuse. In thismanner, when a sufficient number of fuses have been burned, the deviceperforming the process 1000 becomes inoperable to perform additionalpassword verifications (at least for a hardware secret associated withthe fuses).

Variations of the process 1000 are considered as being within the scopeof the present disclosure. For example, the process may vary inaccordance with the number of fuses relative to the number of passcodeverifications a device is allowed to perform. For instance, in someembodiments, a device maintains a counter and burns a fuse and resetsthe counter each time the counter reaches a specified threshold. Inother embodiments, there may be more fuses than a number of passcodeverifications the device is allowed to perform and, therefore, theprocess 1000 may include burning multiple fuses for each passcodeverification. Further, stochastic techniques may be incorporated indeterminations whether to burn a fuse. Referring to FIG. 9, for example,when a random number satisfies the one or more conditions, a fuse may beburned. Other variations are also considered as being within the scopeof the present disclosure.

In some embodiments, a device that has become inoperable to performpasscode verifications may be refreshed so that the device is able toperform additional operations using the same hardware secret. FIG. 11,accordingly, shows an illustrative example of a process 1100 that may beused to enforce limits on numbers of passcode verifications that may beperformed while allowing for refreshing of the number of operations. Theprocess 1100 may be performed by any suitable device, such as the device700 described above in connection with FIG. 7. In an embodiment, theprocess 1100 includes receiving 1102 a passcode verification request andperforming 1104 a passcode verification process, such as describedabove. A counter, which correlates to a number of passcode may also beupdated 1106. A determination may be made 1108 whether the counter hasreached a first limit. The first limit may correspond to a number ofoperations that may be performed by the device performing the process1100 before the device, in accordance with how it is configured,requests a refresh in the number of operations it may perform. Ifdetermined 1108 that the first limit has not been reached, the process1100 may repeat as described above as passcode verification requests arereceived 1102.

When determined 1108 that the first limit has been reached, the processmay include requesting 1110 a refresh. Requesting a refresh may beperformed in various ways in accordance with various embodiments and inaccordance with the capabilities of the device performing the process1100. For example, the device may be configured to transmit anotification of reaching the first limit over a network to a particularIP address or to an IP address corresponding to a particular URL. Asanother example, if so equipped, the device may cause a display deviceto display an indication of a need to refresh. As yet another example,the device may store an indication of the need to refresh in memory sothat the indication will be detected at a later time. For instance, inthe example of an ATM, a service technician may (through an appropriatedevice) detect the indication when the ATM is refilled with funds. Inthe example of a smartcard, the indication may be stored so that thenext time a smartcard is used, a user will see a prompt on a displaydevice associated with a device reading the smartcard. In the example ofa SIM card for a mobile device, the mobile device may display anotification of the need to refresh. Generally, any manner in whichinformation indicating the need for refresh may be issued may be usedand combinations of methods may also be used.

The process 1100 may also include determining 1112 whether a secondlimit has been reached, where the second limit may correspond to a limiton the number of operations the device performing the process 1100 mayperform without refresh. If determined 1112 that the second limit hasnot been reached, the process 1100 may repeat as discussed above aspasscode verification requests are received 1102. If, however, it isdetermined 1112 that the second limit has been reached, the process mayinclude performing 1114 a process corresponding to having reached thesecond limit. The process corresponding to having reached the secondlimit may render a device performing the process 700 temporarily orpermanently inoperable to verify passcodes. If inoperability istemporary, the device may remain inoperable until the device isrefreshed with additional operations, if such should occur.

FIG. 12 shows an illustrative example of a process 1200 which may beused to receive a refresh that enables additional passcodeverifications. The process 1200 may be performed by any suitable device,such as a device 700 described above in connection with FIG. 7. In anembodiment, the process 1200 includes receiving 1202 a passcode refreshcommunication with a digital signature. The passcode refreshcommunication may be received in various ways in various embodiments,and the ways in which the communication is made may vary in accordancewith the type of device performing the process 1200. For example, insome embodiments, the communication is received over a network. In otherexamples, the communication is received via a locally attached (e.g.,physically attached device or device on a secure private network). Insome embodiments, the refresh communication originates from a universalserial bus (USB) or other attachable device that is not accessible overa network. Generally, the refresh communication may be any communicationformatted and transmitted in accordance with the abilities of the deviceperforming the process 1200.

In an embodiment, the process 1200 includes determining 1204 whether thedigital signature is valid. The way by which it is determined 1204whether the digital signature is valid may vary in differentembodiments. For example, in some embodiments, the digital signature isgenerated using a copy of a hardware secret that the device performingthe process 1200 has, which may be the same hardware secret used toverify passcodes or a different hardware secret. (Copies of hardwaresecrets may, for example, be maintained securely, such as off of apublicly-accessible network, in an HSM, and/or otherwise). Thus,determining 1204 whether the digital signature is valid may includeusing the hardware secret to generate a reference digital signaturebased at least in part on the received communication and comparing thereference digital signature to the digital signature that was received.Similarly, the received digital signature may have been generated usinga secret accessible to the device performing the process 1200, but thatis not a hardware secret. Accordingly, the secret may be used togenerate a reference signature that is compared with the receivedsignature. In some embodiments, an asymmetric digital signature schemeis used. In such embodiments, the digital signature may be generatedusing a private key of a public-private key pair and verified by thedevice performing the process 1200 using a public key of thepublic-private key pair and possible communication with an appropriatecertificate authority. Generally, any way by which the digital signatureand, generally, the authenticity of the refresh communication may beverified may be used.

If determined 1204 that the digital signature is valid, the process 1200may include performing 1206 a refresh. Performing a refresh may beperformed in any suitable manner, and the manner by which the refresh isperformed may vary in accordance with various embodiments. In someembodiments, performing the refresh includes resetting a counter thatenables additional passcode verifications to be performed. Referring toembodiments discussed above, the reset counter may be maintained by ahardware module that is configured to perform one or moreself-destructive operations that result in destruction of the hardwaresecret if the counter reaches a threshold. In some embodiments,performing the refresh includes receiving an update to a passcodedatabase utilized by a device performing the process 1200, such asdescribed above. If, however, it is determined 1204 that the digitalsignature is invalid, the process 1204 may include denying the refresh,which may include not resetting a counter, incrementing a counterfurther (e.g., to cause a self-destruct operation to occur sooner),communicating the denial and/or one or more reasons for the denialand/or otherwise.

In some embodiments, the various techniques described herein are usableto implement a distributed passcode verification system where passcodeverifiers are decentralized, configured to make authenticationdeterminations using a limited number of tests, which may be a fixednumber of tests or a number of tests that is otherwise limited, and/orwhich may be refreshed. FIG. 13 shows an illustrative example of anenvironment 1300 in which various embodiments may be practiced. In anembodiment, the environment 1300, includes a passcode informationmanager 1302 which may be a computer system or programming moduleoperating thereon that is configured to manage passcode information fora service, such as a directory service or other system for whichpasscodes are used as a way to prevent unauthorized access. In anembodiment, the passcode information manager 1302 generates and providesinformation to a plurality of computing devices 1304, which may belaptop/notebook computer systems, tablet computer systems, and/or othercomputer systems. The computing devices 1304 may be configured withhardware secrets and configured to be able to perform a limited numberof passcode verifications, which may be refreshable, such as describedabove.

In an embodiment, the passcode information manager 1302 providespasscode information 1306 to the computing devices 1304. The passcodeinformation 1306, in an embodiment, is information usable to verifypasscodes input into the computing devices 1304. The passcodeinformation 1306 may, for instance, comprise information stored in apasscode database, discussed above. Further, in various embodiments, thepasscode information includes information usable to verify passcodescorresponding to multiple users, such as a plurality of users in acorporate directory. In some embodiments, for example, the passcodeinformation manager 1302 provides the passcode information 1306 to acomputing device 1304 when the computing device 1304 connects (e.g.,establishes a secure connection and/or authenticates) to a corporate orother network associated with the passcode information. The passcodeinformation manager 1302 may, for instance, provide updated passcodeinformation 1306 when the passcode information it manages is updated,such as when users change passcodes, new users are added to a directoryand the like. In some embodiments, the passcode information is providedto the computing devices 1304 from the passcode information manager 1302indirectly. For instance, the passcode information manager 1302 maypublish the passcode information 1306 to a website, which may be apublicly accessible website, that the computing devices 1304 areconfigured to poll periodically or aperiodically.

In various embodiments, the computing devices 1304 are each equippedwith one or more hardware secrets, such as in one or more ways describedabove. The passcode information 1306 for each computing device 1304 maybe specifically configured for the computing device 1304 using a copy ofthe hardware secret. In some embodiments, the passcode informationmanager 1302 has access to a copy of the hardware secret of eachcomputing device 1304. In other embodiments, passcodes are provided toanother system that securely stores copies of hardware secrets forgeneration of passcode information. Further, in some embodiments,instead of computing device-specific passcode information, eachcomputing device 1304 may receive the same passcode information, whichmay, for multiple passcodes, include multiple hash values for the samepasscode, each generated using a copy of a different hardware secret. Acomputing device 1304 may select an appropriate hash value for verifyinga passcode or may verify a passcode by using its hardware secret togenerate a hash value and checking if the hash value appears in thepasscode information. Other variations are also considered as beingwithin the scope of the present disclosure.

By providing passcode information 1306 to the computing devices 1304,the computing devices 1304 are able to verify passcodes without havingto be connected to a corporate or other network. Further, multiple usersmay be able to log in to a single computing device 1304 (therebyaccessing additional computing functionality, such as operating systemfunctionality) since the computing device 1304 has the passcodeinformation 1306 without having to connect to a network to verifypasscodes.

In some embodiments, a limit on a number of passcode verifications thatmay be performed by a computing device 1304 may be refreshed each timethe computing device connects to a specified network (e.g., corporatenetwork) using techniques described above. Moreover, because of alimited number of passcode verifications that are performable, theft orother unauthorized access to a computing device 1304 provideseffectively zero information usable to gain unauthorized access tosensitive information. For example, the limit on passcode verificationsthat may be performed may be configured such that brute force (e.g.,passcode guessing) attacks are highly probable (e.g., are probable abovesome specified probability) to fail before the computing device 1304becomes unable to perform additional passcode verifications, possiblydue to physical self-destruction, in some embodiments. However, asnoted, as long as the computing device 1304 regularly performs one ormore specified operations (e.g., connecting to a corporate network), thelimit is refreshed so that the computing device 1304 remains able toperform passcode verifications for multiple users.

The techniques illustrated in FIG. 13 are also usable in other contexts.For example, FIG. 14 shows an illustrative example of an environment1400 in which various techniques of the present disclosure may be used.The environment 1400, in this example, includes a passcode informationmanager 1402, which may be a system or programming module operatingthereon configured to manage passcode information such as describedabove. The passcode information manager 1402 may be configured to causethe transmission of passcode information, such as described above inFIG. 13, although in the environment 1400, the passcode informationmanager 1402 may utilize appropriate systems (e.g., satellite uplinksystem, not shown) to transmit the passcode information to a satellite1404 or other system for distributing content and other informationassociated therewith (e.g., passcode information). Further, passcodeinformation may include additional information, such as informationassociated with accounts that indicates what content each account isallowed to view. For example, in addition to a hash of a passcodegenerated based at least in part on a hardware secret and associatedwith an account, the passcode information may include informationindicating a set of channels that the corresponding account is allowedto view (i.e., have decoded). Information may be provided to/from thesatellite 1404 utilizing one or more appropriate protocols, such as thedigital video broadcasting (DVB) S2, Integrated Services DigitalBroadcasting (ISDB)-S and/or S-Digital Multimedia Broadcasting (DMB)protocol.

Passcode information received by the satellite 1404 from the passcodeinformation manager 1402 may be transmitted through one or moresatellite antennas (dishes) 1406 to corresponding satellite receivers1408. A satellite receiver, in an embodiment, is a device configured toconvert signals received from a satellite antenna 1406 into signalsappropriate for media consumption (e.g., by converting to a videosignal). In various embodiments, a satellite receiver 1408 receivessignals for multiple sources of content (e.g., television channels). Thesources for which a receiver 1408 will convert signals to video signals(which may include decryption of encrypted content) may vary amongcustomers in accordance with various account types of a contentprovider. For example, one user may have a basic programming packagethat provides access to a first set of channels while a second user mayhave a costlier programming package that provides access to a larger,second set of channels. The satellite receivers 1408 may be configuredto receive and, using a hardware secret as described above, verifypasscodes to determine which channels to decode.

In an embodiment, because the passcode information provided to thesatellite receivers 1408 is usable to verify passcodes for multipleaccounts, users are able to provide credentials to others' satellitereceivers in order to access decoded content. For example, a first usermay have a first programming package and a second user may have a secondprogramming package with a channel that is not available in the firstprogramming package. The second user may log into the first user'ssatellite receiver to access the channel not available in the firstprogramming package. If the first user and second user are friends, forexample, and want to watch programming together, the users are notlimited to using the second user's satellite receiver because the seconduser is able to log in using any receiver that is configured to be ableto receive and utilize the passcode information transmitted form thesatellite 1404.

Various techniques described above may be incorporated into operation ofthe environment 1400. For example, as noted, satellite receivers may beconfigured with hardware secrets that are used to verify passcodes. Insome embodiments, each satellite receiver may be configured with theability to perform a limited number of tests before becoming inoperableto verify passcodes, at least temporarily. In some embodiments, eachsatellite receiver is provided with a fixed number of tests that isperiodically refreshed (e.g., once per month) by transmissions from thesatellite 1404 (or by another channel, such as an Internet connection tothe satellite receiver 1408). The fixed number (or other limit) may beconfigured such that a satellite receiver is able to perform a number ofpasscode verifications that is likely to exceed an amount actuallyneeded (e.g., several hundred per month), but such that any brute forceor other attack to determine the hardware secret or otherwise enableunauthorized access to programming would render the satellite receiverinoperable, either permanently or until refreshed.

The environment 1400 is illustrative in nature and the techniquesdiscussed herein are applicable in a wide variety of contexts. Forexample, in some embodiments, a device configured to perform a limitednumber of passcode verifications may be configured to controlunauthorized access to software functionality, such as for high-valuesoftware. In some embodiments, for instance, a dongle (e.g., device thatcommunicates with a computer system via a USB connection) is requiredfor access to some or all software functionality. A software applicationmay be configured to periodically or otherwise provide a challenge tothe dongle and the dongle must use a hardware secret to successfullycomplete the challenge. (For instance, in some embodiments, the donglemust compute a hash value from a hardware secret to be checked by acomputer system that, as a result of executing the software, has a copyof the hash value or is able to determine the hash value). The softwaremay be configured such that some or all functionality requires thedongle to successfully complete the challenge. In other embodiments, thesoftware includes obfuscated (e.g., encrypted) code that isunobfuscatable using a hardware secret in the dongle. To utilizefunctionality dependent on the code, the software may require that thecode become unobfuscated, which would require the dongle to unobfuscate(e.g., decrypt) the code. In other embodiments, certain functionalitymay require code stored on the dongle in a manner obfuscated so as to beunobfuscatable using a hardware secret of the dongle. The software maycause a system executing the software to make calls to the dongle (e.g.,by way of a dynamic-link library), to cause the dongle to use itshardware secret to deobfuscate and perform operations using its code tothereby allow for full functionality. Such a dongle may have access to alimited number of passcode verifications that is configured to be enoughfor a useful life of the software (e.g., enough passcode verificationsexpected to be needed for a specified number of years), but too few tomake unauthorized access to the dongle effectively useless to enable asuccessful cryptographic attack to gain unauthorized access to softwarefunctionality. As above, a dongle may be configured to cease operatingusing a hardware secret, to perform self-destructive operations, and/orto be refreshable.

In other embodiments, the techniques described and suggested herein areapplicable to documents rights management. A corporate computer (e.g.,notebook computer) may, for instance, require use of a hardware secretto access documents in a corporate document repository (e.g., documentmanagement system). The computer may have access to a limited number ofoperations where the limit is based at least in part on a determinationof a reasonable number of documents an employee would need to accessduring a time period (e.g., the life of the computer, a month (if thelimit is refreshable)). For example, each attempt to access a documentmust require use of a hardware secret to be successful, in someembodiments. In this manner, normal use of the computer does not invokethe limit, but unauthorized events, such as a mass export of documentsfrom the document repository may trigger the limit and, thereby, preventsuch an unauthorized mass export.

Further, as noted, limits on passcode verifications may be enforced invarious ways in accordance with various embodiments. For example, insome embodiments, limits are statistically enforced such that a rate atwhich passcode verifications (or other, related operations) areperformed is limited by a maximum value and a maximum average value,where verifications at a rate faster than the maximum average value areallowed as long as the average number of verifications performed mustremain at or below the maximum average value.

Further, while various embodiments are described in connection withparticular cryptographic processes (e.g., verifying passcodes throughhash value calculations), the techniques described and suggested hereinare applicable in other contexts with other types of cryptographicoperations, such as encryption and decryption. In some embodiments, thetechniques described and suggested herein are used in connection withfull disk encryption for computing devices. A computer may need todecrypt a local storage device (e.g., hard drive) at each reboot (orother event). A cryptographic module (e.g., a TPM) of the computer maybe provided with a limited number of decryptions utilizing one or moreof the techniques described above. Connections to a corporate or othernetwork may cause the limit to be refreshed, either each time or if thenumber of decryptions and/or other related operations drops below athreshold. In this manner, if the computer is stolen or otherwisecompromised, only a limited number of login attempts are allowed beforedecryption is no longer possible (permanently or until refresh). As aresult, compromise of data stored on the computer is prevented.

Further enhancements of the various techniques described and suggestedherein are also considered as being within the scope of the presentdisclosure. For example, some devices may have location sensingcapabilities (such as global positioning system (GPS) capabilities)where the devices are able to receive signals (e.g., from satellites,cellular towers, wireless routers and/or other sources) and determinetheir proximate locations from the signals. Such a device may beconfigured to only perform cryptographic operations using a hardwaresecret when the device detects that it is in an approved location, whichmay be defined as within a specified radius of a geographic point. Othervariations are also considered as being within the scope of the presentdisclosure.

FIG. 15 illustrates aspects of an example environment 1500 forimplementing aspects in accordance with various embodiments. As will beappreciated, although a web-based environment is used for purposes ofexplanation, different environments may be used, as appropriate, toimplement various embodiments. The environment includes an electronicclient device 1502, which can include any appropriate device operable tosend and/or receive requests, messages or information over anappropriate network 1504 and, in some embodiments, convey informationback to a user of the device. Examples of such client devices includepersonal computers, cell phones, handheld messaging devices, laptopcomputers, tablet computers, set-top boxes, personal data assistants,embedded computer systems, electronic book readers and the like. Thenetwork can include any appropriate network, including an intranet, theInternet, a cellular network, a local area network, a satellite networkor any other such network and/or combination thereof. Components usedfor such a system can depend at least in part upon the type of networkand/or environment selected. Protocols and components for communicatingvia such a network are well known and will not be discussed herein indetail. Communication over the network can be enabled by wired orwireless connections and combinations thereof. In this example, thenetwork includes the Internet, as the environment includes a web server1506 for receiving requests and serving content in response thereto,although for other networks an alternative device serving a similarpurpose could be used as would be apparent to one of ordinary skill inthe art.

The illustrative environment includes at least one application server1508 and a data store 1510. It should be understood that there can beseveral application servers, layers or other elements, processes orcomponents, which may be chained or otherwise configured, which caninteract to perform tasks such as obtaining data from an appropriatedata store. Servers, as used herein, may be implemented in various ways,such as hardware devices or virtual computer systems. In some contexts,servers may refer to a programming module being executed on a computersystem. As used herein, unless otherwise stated or clear from context,the term “data store” refers to any device or combination of devicescapable of storing, accessing and retrieving data, which may include anycombination and number of data servers, databases, data storage devicesand data storage media, in any standard, distributed, virtual orclustered environment. The application server can include anyappropriate hardware, software and firmware for integrating with thedata store as needed to execute aspects of one or more applications forthe client device, handling some or all of the data access and businesslogic for an application. The application server may provide accesscontrol services in cooperation with the data store and is able togenerate content including, but not limited to, text, graphics, audio,video and/or other content usable to be provided to the user, which maybe served to the user by the web server in the form of HyperText MarkupLanguage (“HTML”), Extensible Markup Language (“XML”), JavaScript,Cascading Style Sheets (“CSS”), or another appropriate client-sidestructured language. Content transferred to a client device may beprocessed by the client device to provide the content in one or moreforms including, but not limited to, forms that are perceptible to theuser audibly, visually and/or through other senses including touch,taste, and/or smell. The handling of all requests and responses, as wellas the delivery of content between the client device 1502 and theapplication server 1508, can be handled by the web server using PHP:Hypertext Preprocessor (“PHP”), Python, Ruby, Perl, Java, HTML, XML, oranother appropriate server-side structured language in this example. Itshould be understood that the web and application servers are notrequired and are merely example components, as structured code discussedherein can be executed on any appropriate device or host machine asdiscussed elsewhere herein. Further, operations described herein asbeing performed by a single device may, unless otherwise clear fromcontext, be performed collectively by multiple devices, which may form adistributed and/or virtual system.

The data store 1510 can include several separate data tables, databases,data documents, dynamic data storage schemes and/or other data storagemechanisms and media for storing data relating to a particular aspect ofthe present disclosure. For example, the data store illustrated mayinclude mechanisms for storing production data 1512 and user information1516, which can be used to serve content for the production side. Thedata store also is shown to include a mechanism for storing log data1514, which can be used for reporting, analysis or other such purposes.It should be understood that there can be many other aspects that mayneed to be stored in the data store, such as page image information andaccess rights information, which can be stored in any of the abovelisted mechanisms as appropriate or in additional mechanisms in the datastore 1510. The data store 1510 is operable, through logic associatedtherewith, to receive instructions from the application server 1508 andobtain, update or otherwise process data in response thereto. Theapplication server 1508 may provide static, dynamic or a combination ofstatic and dynamic data in response to the received instructions.Dynamic data, such as data used in web logs (blogs), shoppingapplications, news services and other such applications may be generatedby server-side structured languages as described herein or may beprovided by a content management system (“CMS”) operating on, or underthe control of, the application server. In one example, a user, througha device operated by the user, might submit a search request for acertain type of item. In this case, the data store might access the userinformation to verify the identity of the user and can access thecatalog detail information to obtain information about items of thattype. The information then can be returned to the user, such as in aresults listing on a web page that the user is able to view via abrowser on the user device 1502. Information for a particular item ofinterest can be viewed in a dedicated page or window of the browser. Itshould be noted, however, that embodiments of the present disclosure arenot necessarily limited to the context of web pages, but may be moregenerally applicable to processing requests in general, where therequests are not necessarily requests for content.

Each server typically will include an operating system that providesexecutable program instructions for the general administration andoperation of that server and typically will include a computer-readablestorage medium (e.g., a hard disk, random access memory, read onlymemory, etc.) storing instructions that, when executed by a processor ofthe server, allow the server to perform its intended functions. Suitableimplementations for the operating system and general functionality ofthe servers are known or commercially available and are readilyimplemented by persons having ordinary skill in the art, particularly inlight of the disclosure herein.

The environment, in one embodiment, is a distributed and/or virtualcomputing environment utilizing several computer systems and componentsthat are interconnected via communication links, using one or morecomputer networks or direct connections. However, it will be appreciatedby those of ordinary skill in the art that such a system could operateequally well in a system having fewer or a greater number of componentsthan are illustrated in FIG. 15. Thus, the depiction of the system 1500in FIG. 15 should be taken as being illustrative in nature and notlimiting to the scope of the disclosure.

The various embodiments further can be implemented in a wide variety ofoperating environments, which in some cases can include one or more usercomputers, computing devices or processing devices which can be used tooperate any of a number of applications. User or client devices caninclude any of a number of general purpose personal computers, such asdesktop, laptop or tablet computers running a standard operating system,as well as cellular, wireless and handheld devices running mobilesoftware and capable of supporting a number of networking and messagingprotocols. Such a system also can include a number of workstationsrunning any of a variety of commercially-available operating systems andother known applications for purposes such as development and databasemanagement. These devices also can include other electronic devices,such as dummy terminals, thin-clients, gaming systems and other devicescapable of communicating via a network. These devices also can includevirtual devices such as virtual machines, hypervisors and other virtualdevices capable of communicating via a network.

Various embodiments of the present disclosure utilize at least onenetwork that would be familiar to those skilled in the art forsupporting communications using any of a variety ofcommercially-available protocols, such as Transmission ControlProtocol/Internet Protocol (“TCP/IP”), User Datagram Protocol (“UDP”),protocols operating in various layers of the Open System Interconnection(“OSI”) model, File Transfer Protocol (“FTP”), Universal Plug and Play(“UpnP”), Network File System (“NFS”), Common Internet File System(“CIFS”), and AppleTalk. The network can be, for example, a local areanetwork, a wide-area network, a virtual private network, the Internet,an intranet, an extranet, a public switched telephone network, aninfrared network, a wireless network, a satellite network and anycombination thereof.

In embodiments utilizing a web server, the web server can run any of avariety of server or mid-tier applications, including Hypertext TransferProtocol (“HTTP”) servers, FTP servers, Common Gateway Interface (“CGI”)servers, data servers, Java servers, Apache servers, and businessapplication servers. The server(s) also may be capable of executingprograms or scripts in response to requests from user devices, such asby executing one or more web applications that may be implemented as oneor more scripts or programs written in any programming language, such asJava®, C, C#, or C++, or any scripting language, such as Ruby, PHP,Perl, Python, or TCL, as well as combinations thereof. The server(s) mayalso include database servers, including without limitation thosecommercially available from Oracle®, Microsoft®, Sybase®, and IBM® aswell as open-source servers such as MySQL, Postgres, SQLite, MongoDB,and any other server capable of storing, retrieving and accessingstructured or unstructured data. Database servers may includetable-based servers, document-based servers, unstructured servers,relational servers, non-relational servers or combinations of theseand/or other database servers.

The environment can include a variety of data stores and other memoryand storage media as discussed above. These can reside in a variety oflocations, such as on a storage medium local to (and/or resident in) oneor more of the computers or remote from any or all of the computersacross the network. In a particular set of embodiments, the informationmay reside in a storage-area network (“SAN”) familiar to those skilledin the art. Similarly, any necessary files for performing the functionsattributed to the computers, servers or other network devices may bestored locally and/or remotely, as appropriate. Where a system includescomputerized devices, each such device can include hardware elementsthat may be electrically coupled via a bus, the elements including, forexample, at least one central processing unit (“CPU” or “processor”), atleast one input device (e.g., a mouse, keyboard, controller, touchscreen or keypad), and at least one output device (e.g., a displaydevice, printer or speaker). Such a system may also include one or morestorage devices, such as disk drives, optical storage devices, andsolid-state storage devices such as random access memory (“RAM”) orread-only memory (“ROM”), as well as removable media devices, memorycards, flash cards, etc.

Such devices also can include a computer-readable storage media reader,a communications device (e.g., a modem, a network card (wireless orwired), an infrared communication device, etc.) and working memory asdescribed above. The computer-readable storage media reader can beconnected with, or configured to receive, a computer-readable storagemedium, representing remote, local, fixed and/or removable storagedevices as well as storage media for temporarily and/or more permanentlycontaining, storing, transmitting and retrieving computer-readableinformation. The system and various devices also typically will includea number of software applications, modules, services or other elementslocated within at least one working memory device, including anoperating system and application programs, such as a client applicationor web browser. It should be appreciated that alternate embodiments mayhave numerous variations from that described above. For example,customized hardware might also be used and/or particular elements mightbe implemented in hardware, software (including portable software, suchas applets) or both. Further, connection to other computing devices suchas network input/output devices may be employed.

Storage media and computer readable media for containing code, orportions of code, can include any appropriate media known or used in theart, including storage media and communication media, such as, but notlimited to, volatile and non-volatile, removable and non-removable mediaimplemented in any method or technology for storage and/or transmissionof information such as computer readable instructions, data structures,program modules or other data, including RAM, ROM, Electrically ErasableProgrammable Read-Only Memory (“EEPROM”), flash memory or other memorytechnology, Compact Disc Read-Only Memory (“CD-ROM”), digital versatiledisk (DVD) or other optical storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices or any othermedium which can be used to store the desired information and which canbe accessed by the system device. Based on the disclosure and teachingsprovided herein, a person of ordinary skill in the art will appreciateother ways and/or methods to implement the various embodiments.

The specification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense. It will, however, beevident that various modifications and changes may be made thereuntowithout departing from the broader spirit and scope of the invention asset forth in the claims.

Other variations are within the spirit of the present disclosure. Thus,while the disclosed techniques are susceptible to various modificationsand alternative constructions, certain illustrated embodiments thereofare shown in the drawings and have been described above in detail. Itshould be understood, however, that there is no intention to limit theinvention to the specific form or forms disclosed, but on the contrary,the intention is to cover all modifications, alternative constructionsand equivalents falling within the spirit and scope of the invention, asdefined in the appended claims.

The use of the terms “a” and “an” and “the” and similar referents in thecontext of describing the disclosed embodiments (especially in thecontext of the following claims) are to be construed to cover both thesingular and the plural, unless otherwise indicated herein or clearlycontradicted by context. The terms “comprising,” “having,” “including,”and “containing” are to be construed as open-ended terms (i.e., meaning“including, but not limited to,”) unless otherwise noted. The term“connected,” when unmodified and referring to physical connections, isto be construed as partly or wholly contained within, attached to orjoined together, even if there is something intervening. Recitation ofranges of values herein are merely intended to serve as a shorthandmethod of referring individually to each separate value falling withinthe range, unless otherwise indicated herein and each separate value isincorporated into the specification as if it were individually recitedherein. The use of the term “set” (e.g., “a set of items”) or “subset”unless otherwise noted or contradicted by context, is to be construed asa nonempty collection comprising one or more members. Further, unlessotherwise noted or contradicted by context, the term “subset” of acorresponding set does not necessarily denote a proper subset of thecorresponding set, but the subset and the corresponding set may beequal.

Conjunctive language, such as phrases of the form “at least one of A, B,and C,” or “at least one of A, B and C,” unless specifically statedotherwise or otherwise clearly contradicted by context, is otherwiseunderstood with the context as used in general to present that an item,term, etc., may be either A or B or C, or any nonempty subset of the setof A and B and C. For instance, in the illustrative example of a sethaving three members, the conjunctive phrases “at least one of A, B, andC” and “at least one of A, B and C” refer to any of the following sets:{A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such conjunctivelanguage is not generally intended to imply that certain embodimentsrequire at least one of A, at least one of B and at least one of C eachto be present.

Operations of processes described herein can be performed in anysuitable order unless otherwise indicated herein or otherwise clearlycontradicted by context. Processes described herein (or variationsand/or combinations thereof) may be performed under the control of oneor more computer systems configured with executable instructions and maybe implemented as code (e.g., executable instructions, one or morecomputer programs or one or more applications) executing collectively onone or more processors, by hardware or combinations thereof. The codemay be stored on a computer-readable storage medium, for example, in theform of a computer program comprising a plurality of instructionsexecutable by one or more processors. The computer-readable storagemedium may be non-transitory.

The use of any and all examples, or exemplary language (e.g., “such as”)provided herein, is intended merely to better illuminate embodiments ofthe invention and does not pose a limitation on the scope of theinvention unless otherwise claimed. No language in the specificationshould be construed as indicating any non-claimed element as essentialto the practice of the invention.

Preferred embodiments of this disclosure are described herein, includingthe best mode known to the inventors for carrying out the invention.Variations of those preferred embodiments may become apparent to thoseof ordinary skill in the art upon reading the foregoing description. Theinventors expect skilled artisans to employ such variations asappropriate and the inventors intend for embodiments of the presentdisclosure to be practiced otherwise than as specifically describedherein. Accordingly, the scope of the present disclosure includes allmodifications and equivalents of the subject matter recited in theclaims appended hereto as permitted by applicable law. Moreover, anycombination of the above-described elements in all possible variationsthereof is encompassed by the scope of the present disclosure unlessotherwise indicated herein or otherwise clearly contradicted by context.

All references, including publications, patent applications and patents,cited herein are hereby incorporated by reference to the same extent asif each reference were individually and specifically indicated to beincorporated by reference and were set forth in its entirety herein.

What is claimed is:
 1. A computer-implemented method, comprising: underthe control of a computing device, storing, in the computing device, asecret that: has a usage limit that corresponds to a quota on a numberor rate of cryptographic operations performable using the secret, thecomputing device being unable to unilaterally exceed the usage limit;and is securely stored by the computing device so as to be at leastprogrammatically unexportable from the computing device; performing oneor more cryptographic operations using the secret of the one or morehardware secrets, where, as a result of the secret being associated withthe usage limit, the one or more operations are performed in accordancewith the usage limit; and providing a result of performance of the oneor more cryptographic operations.
 2. The computer-implemented method ofclaim 1, wherein the first usage limit controls a total number ofcalculations involving the secret performable by the computing devicebefore the device is unable to perform cryptographic operations usingthe secret.
 3. The computer-implemented method of claim 2, furthercomprising performing one or more operations that cause the usage limitto be increased as a result of authorization for an increase to theusage limit from another computing device.
 4. The computer-implementedmethod of claim 1, wherein the usage limit controls a rate at whichcalculations involving the secret are performable by the computingdevice.
 5. The computer-implemented method of claim 1, furthercomprising, as a result of reaching the at least one usage limit,performing one or more operations that cause physical destruction to thecomputing device thereby disenabling the computing device fromperforming cryptographic operations involving the secret.
 6. Thecomputer-implemented method of claim 1, wherein: a request originatesfrom a second computing device communicatively attached to the computingdevice; and providing the result of performance of the one or morecryptographic operations enables functionality of the second computingdevice.
 7. A device, comprising: one or more processors; and memory;wherein the memory and one or more processors are collectivelyconfigured such that: the device stores secret information so as to beunexportable from the device; the one or more processors performcryptographic operations using the secret information subject to a usagelimit associated with the secret information that serves as a quota on anumber of cryptographic operations performable by the one or moreprocessors, the usage limit different from a clock rate limit for theone or more processors and the device being unable to unilaterally resetthe usage limit; and the device provides results of performance of thecryptographic operations.
 8. The device of claim 7, wherein thecryptographic operations include passcode verification.
 9. The device ofclaim 7, wherein the cryptographic operations include decryption of dataencrypted under the secret information.
 10. The device of claim 7,further comprising an interface that receives requests locally fromanother device, each request of the received requests being fulfillableby performance of at least one cryptographic operation using the secretinformation.
 11. The device of claim 7, wherein: the quota is a limitfor a total number of cryptographic operations using the secretinformation performable by the device; and the one or more processorsfurther destroy the secret information as a result of reaching the totalnumber of cryptographic operations.
 12. The device of claim 7, wherein:the device further comprises a plurality of fuses; and the one or moreprocessors further enforce the usage limit by burning the fuses.
 13. Thedevice of claim 7, wherein: the device further comprises an interfacethat enables communication with another device; and the one or moreprocessors, as a result of receiving information indicatingauthorization by the other device to refresh the usage limit, enable thedevice to perform additional cryptographic operations beyond the usagelimit.
 14. The device of claim 7, wherein: the cryptographic operationsare cryptographic verifications each having a positive or negativeoutcome; and the usage limit applies to both cryptographic verificationshaving positive outcomes and cryptographic verifications having negativeoutcomes.
 15. A non-transitory computer-readable storage medium havingstored thereon instructions that, as a result of execution by one ormore processors of a device, cause the device to: detect a requirementfor performance of one or more cryptographic operations using a secretstored in the device so as to be unexportable from the device; as aresult of detecting the requirement, cause a component of the devicehaving access to the secret to perform the one or more cryptographicoperations in accordance with a usage limit applied to the secret, thedevice unable to unilaterally reset the usage limit; and provide aresult of performance of the one or more cryptographic operations. 16.The non-transitory computer-readable storage medium of claim 15, whereinthe usage limit corresponds to a fixed number of cryptographicoperations performable by the device.
 17. The non-transitorycomputer-readable storage medium of claim 16, wherein the instructionsfurther comprise instructions that, as a result of execution by the oneor more processors of the device, cause the device to receiveauthorization to increase the fixed number.
 18. The non-transitorycomputer-readable storage medium of claim 15, wherein the usage limitlimits a rate at which cryptographic operations using the secret areperformable by the device.
 19. The non-transitory computer-readablestorage medium of claim 15, wherein the instructions further compriseinstructions that, as a result of execution by the one or moreprocessors, cause the device to detect a trigger and, as a result ofdetecting the trigger, request an increase to the usage limit fromanother device.
 20. The non-transitory computer-readable storage mediumof claim 19, wherein the trigger is attainment of a first usage limitdifferent from the usage limit.